1. Field of the Invention
The present invention relates generally to financial and investment software, and more particularly to a system, method, and computer program product for automated reconciliation between two differently recorded sets of transaction records.
2. Description of Background Art
Software for managing personal and/or business finances and investments typically provides functionality for reconciling a user-maintained transaction register with a statement provided by a bank or other financial institution. In conventional financial software applications, a reconcile function operates as follows. Upon receiving a statement from the financial institution, the user activates the reconcile function or mode, and specifies a closing date and ending balance for the statement. All transactions in the register are displayed, except those that have previously been cleared against prior statements. Transactions occurring after the closing date may be omitted or displayed differently from other transactions. The user is then given an opportunity to clear individual transactions in the register by matching them against transactions in the statement. Once the user has cleared all the transactions from the statement, software 307 compares the statement ending balance, adjusted for uncleared transactions, against the register ending balance. If necessary, and if requested by the user, an adjustment is made to the register. The reconciliation is then complete.
The above-described process entails substantial manual effort by the user. The user must manually review each transaction in the statement and check it against the list of register transactions. This process may be time-consuming and error-prone.
Accordingly, many financial software applications provide an automated reconciliation function, wherein the statement from the financial institution is retrieved (such as from an online source) and downloaded onto the user's computer. Software 307 then automatically compares the retrieved statement with the user-entered register. Software 307 attempts to match downloaded statement transactions with register transactions, by comparing the dates and amounts of the transactions, as well as payee or other descriptive information. Some software applications perform a “fuzzy” match determination, in order to allow for slight differences in dates, amounts, and other descriptive information. For example, such software applications may be able to detect a match between a $36.50 register transaction dated June 24th and a $36.60 statement transaction dated June 26th (thus accounting for bank processing time, inaccuracies in entry of data, and the like). In general, such software applications attempt to mimic the type of judgment call a human would make in performing manual reconciliation. In such software applications, the user may be queried as to whether to match a particular statement transaction against one of a limited group of register transactions (or vice versa), particularly when the “fuzzy” match determination algorithm fails to provide a definitive result.
In general, such prior art systems attempt to take into account discrepancies between user-entered transactions and corresponding bank-entered transactions. However, there are many circumstances in which these systems are not capable of identifying matches, despite the “fuzzy” match capability. In particular, in many situations the bank may combine several transactions that the user has entered separately. Conversely, the user-entered register may contain a combined transaction record reflecting several transactions that the bank has entered separately. Since in such situations the amounts for the transactions differ substantially between the user-entered register and the bank statement, the automated reconciliation function is not able to detect a match.
For example, a user may enter into the software two transactions on a particular date, representing a $457 deposit and a $213 deposit. In the bank's records, these transactions may be recorded as a single transaction in the amount of $670; this may occur, for example, if the user presented the items together when making the deposit at the bank. The above-described automated reconciliation function would fail to detect a match, since no single transaction in the register matches a transaction in the statement. This is undesirable, since the user would then have to manually indicate that these transactions should be cleared.
As another example, in an investment account, a register may record transactions representing user contributions, and may further record separate transactions representing an employer's matching contributions. The financial institution may record the user contribution and the employer contribution together, as a single transaction. Again, the above-described automated reconciliation function would fail to detect a match, since the financial institution's single transaction would not match any single transaction in the register.
What is needed, then, is a system, method, and computer program product for detecting matches between two lists of transactions, where one of the transaction lists contains a combined transaction representing two or more transactions in the other transaction list. What is further needed is an automated reconciliation system, method, and computer program product that is capable of recognizing matches between a combined transaction and separately recorded transactions. What is further needed is an automated reconciliation system, method, and computer program product that is capable of recognizing matches between different combinations of transactions.